test: fix the fleet integration suite's flaky waits - #141

Fixes both flakes in the fleet-integration job: metrics assertions that raced the daemon's sampler, and docker compose failures that were discarded rather than reported.

Summary

• Add wait_for_tokens and use it in test_metrics, which asserted on the engine's counters as soon as the node reported running.
• Route the compose lifecycle commands through a helper that stays quiet on success and prints the captured output and exit code on failure.
• Retry a node restart while waiting for it, instead of issuing one start and assuming it took; dump container state and logs when a wait times out.
• Read fleet status into a variable in wait_for_fleet rather than piping it to grep -q.

Implementation details

The metrics race. running means the engine process is alive (internal/daemon/supervisor.go) and nothing more. The counters take a different path: Daemon.Metrics reports the reading its background sampler last took rather than scraping when asked, and SampleActivity retries every second until the first reading lands. The fake engine is Imposter exec'd by the shim, so it also needs a moment to bind its port. That leaves a window where the state is running, the resource bars render because they come from the node rather than the engine, and the counters do not exist yet — a run landing in it fails prompt tokens and 4096 while RAM passes on the same output, which is what CI showed.

Waiting on readiness would not close it: sampleOnce runs before checkReadyOnce in the same loop iteration, so an engine that comes up between the two reads as ready with no sample behind it until the next tick.

The silent failures. Every docker compose call discarded stdout, stderr and exit status. Two CI failures came out of that: a start laptop that left the node refusing connections for ninety seconds with no explanation, and a bring-up that failed ten seconds in and printed nothing but Tearing down.... The restart is now retried while waiting, so a start that loses the race for its published host port no longer strands the node for the rest of the run.

The pipeline. Under pipefail, a grep -q that matches exits immediately and the writer can take a SIGPIPE, making the pipeline report 141; the ! then reads that as "nothing unreachable", the opposite of what was found. Today's three-line output never fills the pipe buffer so it does not trigger, but it is a wait helper that can report ready when it is not.

Verified by running the suite against Docker locally (all assertions pass), and by exercising restart_node with injected start failures to confirm it retries and recovers.